CLAIMS 



What is claimed is: 

1. In a data processing system executing tasks in different time partitions, a 
method of scheduling tasks comprising: 

determining available slack; and 

allocating slack to tasks in different time partitions. 

2. The method of claim 1 wherein the tasks that are allocated slack are 
aperiodic, non-essential tasks. 

3. The method of claim 2 wherein the tasks comprise essential and non- 
essential tasks, and wherein the tasks that are allocated slack are from the group 
consisting of new non-essential tasks and enhancements to essential tasks. 

4. The method of claim 1 wherein in determining, both timeline slack and 
reclaimed slack are determined. 

5. A machine-readable medium having instructions stored thereon capable of 
causing a processor to carry out a method, the method comprising: 

scheduling tasks to execute in different time partitions; 

determining available slack; and 

allocating slack to tasks in different time partitions. 
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6. In a data processing system executing tasks in different time partitions, a 
method of scheduling tasks comprising: 

collecting unscheduled execution time from at least one time partition; and, 
allocating the unscheduled execution time to a task in another time partition. 

7. The method of claim 6, wherein the task in the other partition is an aperiodic, 
non-essential task. 

8. The method of claim 7, wherein the tasks comprise essential and non- 
essential tasks, and wherein the task in the other partition is from the group 
consisting of new non-essential tasks and enhancements to essential tasks. 

9. The method of claim 6, wherein in collecting unscheduled execution time, 
both timeline slack and reclaimed slack are collected. 

10. A machine-readable medium having instructions stored thereon capable of 
causing a processor to carry out a method, the method comprising: 

scheduling tasks to execute in different time partitions; 

collecting unscheduled execution time from at least one time partition; and 

allocating the unscheduled execution time to a task in another time partition. 

11. In a time-partitioned system executing essential and non-essential tasks, a 
method of scheduling tasks comprising: 

determining available slack from the group consisting of timeline slack and 
reclaimed slack; 

pooling available slack in a common slack pool; and 
allocating slack from the common slack pool to tasks. 
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12. The method of claim 11, wherein in allocating, slack is allocated to non- 
essential tasks. 

13. The method of claim 1 1 , wherein in allocating, slack is allocated to a task 
from the group consisting of new non-essential tasks and enhancements to essential 
tasks. 

14. A machine-readable medium having instructions stored thereon capable of 
causing a processor to carry out a method, the method comprising: 

scheduling tasks to execute in different time partitions; 
determining available slack from the group consisting of timeline slack and 
reclaimed slack; 

pooling available slack in a common slack pool; and 
allocating slack from the common slack pool to tasks. 

15. In a time-partitioned system executing essential and non-essential tasks, a 
method of scheduling tasks comprising: 

determining available timeline slack; 
determining available reclaimed slack; 
pooling available timeline and reclaimed slack; and 
allocating slack to a task in any time partition. 

16. The method of claim 1 5, wherein in allocating, slack is allocated to a non- 
essential task. 

17. The method of claim 1 5, wherein in allocating, slack is allocated to a task 
from the group consisting of new non-essential tasks and enhancements to essential 
tasks. 
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18. A machine-readable medium having instructions stored thereon capable of 
causing a processor to carry out a method, the method comprising: 

scheduling tasks to execute in different time partitions; 

determining available timeline slack; 

determining available reclaimed slack; 

pooling available timeline and reclaimed slack; and 

allocating slack to a task in any time partition. 

19. A time-partitioned system comprising: 
a processor; 

a plurality of tasks operating on the processor, wherein each task of the 
plurality of tasks is of a task type selected from the group consisting of essential and 
non-essential, wherein each task of the plurality of tasks has associated with it at 
least one worst case execution time; and 

an executive in communication with the processor and controlling 
dispatching of tasks on the processor, wherein the executive comprises: 
a first module that determines available slack; and 
a second module that allocates available slack to tasks in different 
time partitions. 

20. The time-partitioned system of claim 19, wherein the first module 
determines available slack by determining slack from the group consisting of 
timeline slack, reclaimed slack, and idle time. 

21 . The time-partitioned system of claim 20, wherein the first module maintains 
a pool of available slack. 

22. The time-partitioned system of claim 20, wherein the first module maintains 
a common pool of available slack that can be used by tasks in any time partition. 

88 

Attorney Docket 256.048US1 Honeywell HI 6-25537 



23. The time-partitioned system of claim 19, wherein the second module 
allocates available slack to tasks that are non-essential. 

24. The time-partitioned system of claim 23, wherein the tasks are from the 
group consisting of new non-essential tasks and enhancements to essential tasks. 

25. The time-partitioned system of claim 23, wherein the executive further 
comprises a third module that assigns different priority levels to tasks. 

26. The time-partitioned system of claim 25, wherein the first module 
determines available slack for tasks at each priority level. 

27. The time-partitioned system of claim 25, wherein the second module 
allocates available slack to tasks in order of priority. 

28. The time-partitioned system of claim 19, wherein the system is a flight 
control system. 

29. The time-partitioned system of claim 19, wherein the system is a real-time 
control system. 

30. The time-partitioned system of claim 19, wherein the executive comprises a 
single set of slack variables and a single slack table. 
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APPENDIX A - TABLES 



Task ID 


Ti 


0>,i 


Xl 


6 


1 


x 2 


7 


1 


x 3 


21 


2 



Table (1) - Periodic Task Set 



Notation 



Description 



n 

Co 

d 



The task in a process with priority level ». In traditional RMA, r» is a single thread and 
the whole system is a single partition. In DEOS, we call r» an aggregate thread. There 
are many threads running at the same rate in DEOS. So, if *. ( i,*i\2, are all the 

threads defined for rate i } r, is the sequence of these threads when run back-to-back. This 
representation allows us to consider slack only in terms of rates and not in terms of threads 
which potentially helps performance significantly. 

The number of distinct (aggregate) threads allowed in the system. This number is fixed 
at system power up. 

The time between dispatches of r». We assume without loss of generality that 
Ti < Ti < ... < T n . T, is also called the period of r». In DEOS, strict inequal- 
ity holds. 

The hyperperiod of the task set. H = lcm(Ti,T2, ...T„). Note that in a harmonic system 
such as DEOS, H -T n . 

The j th dispatch of r». Again, in DEOS, r,j is an aggregate thread. 

The worst case execution time for r tJ . In classical RMS the task.set is fixed so dj = d for 
each dispatch j where j = 1, .., ^. Note that this quantity is computed at each successful 
schedulability test. 

A short hand notation for dj when dj A dk for all j, k 6 {!,..., jc}. ' 



Table (2) - Periodic Thread Specification in Classical RMS 



Notation 


Description 


"••/; 

Ei 

Timet 

7. 


The value j£ for t > m/j is the number of times r, will execute during one period 
defined by T». For a harmonic system, all n,/j are integers. 

The level t slack in the interval [0,j • Ti] assuming all' periodic processes take their worst 
case execution time to complete. 

The dispatch identifier of the next instance of n to complete. If r, is in state Completed- 
ForltsPeriod, this is the next instance, otherwise it is the current instance. This value must 
be maintained at runtime. When aggregate threads are supported, one state variable per 
thread may be necessary. 

The amount of level i or higher aperiodic time that has been consumed since the beginning 
of the hyperperiod. This includes all time consumed by aperiodic task of priority 1, ...,t f 
where periodic process overrun can be considered aperiodic process computation time. 
There is an implicit time argument, so Aperlc^oTime^- /^riodUcrTtme^). 
Level i idle time that has occurred since the beginning of the hyperperiod. This is all the 
time not speiit processing tasks of priority * or higher. In other words, it is all the time 
spent" processing tasks (periodic, aperiodic or, idle) of priority i + 1, ...,n, n + 1 where n is 
the number of rates in the system, and level n + 1 is the idle process. There is an implicit 
time argument, so T3^(e^ = IcA^^Ct). 

The dispatch identifier of t\, or equivalently the period identifier of Ti- There is an implicit 
time argument, so 7»(f) = 7,. 

The amount of level i — 1 slack available in [0, j • T%] which is the amount of time available 
for processing tasks at level t — 1 without causing rj , Ti , r» to miss any of their deadlines 
in that interval. 



Table (3) - Slack Scheduling Specification in the Context of Classical RMS 



Dispatch ID 


1 


2 


3 


4 


5 


6 


7 


Timeline 


5 


10 


15 


20 


25 


30 


35 


Slack y 


4 


9 


14 


19 


24 


29 






12 


25 













Table (4) - Timeline Slack ij 



Dispatch ID 


1 


2 


3 


4 


5 


6 


TimelineSlack(l,30) 


4 


8 


12 


16 


20 


24 


TimelineSlack(2,30) 


6 


12 


18 








TimelineSlack(3,30) 


10 













Table (5) - TimelineSlackij 



Thread Servics 



Description 



] createThread 
[K startThread 

?\\ startThreads 



rest artTh read 
killThread 



stopThread 
waitUntilNextPeriod 



restartProcess 

createMutex 

lockMutex 

unlockMutex 

resetMutex 

waitForEvent 
pulseEvent 



Creates a. new thread. If the thread is dynamic, it also starts the thread. 

Schedules to have the (static) thread started at the beginning of the next period defined 
by the threads rate, after the start service has completed. 

Schedules to have the set of threads started at the beginning of each of their respective 
periods defined by their rates, after the start threads service has completed. 

An active thread is restarted from the beginning. 

An active dynamic thread is deactivated. A stopped static thread is also deactivated. 

This routine is newly added. Static threads must first be stopped before they can be killed. 
The calling thread is suspended until the start of its next period where it resumes execution. 
Other threads queued at a mutex that the calling thread holds will be dequeued. 

All the process' threads, mutexes and events are killed. The process* PRIMARY THREAD is 
restarted. 

Creates a mutex that can be accessed by multiple threads in the calling thread's process. 

The calling thread is granted the lock if the mutex is unlocked and queues if waitlok is sc 
true. 

A thread releases its lock on a mutex and the lock is granted to the highest priority thread 
(if any) waiting. 

All threads queued at the mutex are dequeued (including an executing thread). 
The calling thread is suspended until the event is pulsed. 

All threads currently waiting for the pulsed event will transition from state suspended to 
state ready. 



Table (6) - Thread Services 



Notation 


Description 


r, 
n 

Ti 
7» 

mi(t) 

a 

»<|i 

a 

Z 

a 

U B 


The aggregate of threads with priority level t. We call r, an aggregate thread. 

The number of distinct rates allowed in the system. This number is fixed between 

coldstarts. 

The j th thread of priority level «. Even though there is no explicit ordering of threads 
within a priority level, it is convenient to do so for the sake of reference. 
The time between dispatches of r,. We assume without loss of generality that 
7i < T 2 < ... < T«. 

The period identifier. At time t where t 6 [0, H] t 7,*(t) = 7, = fy|. 

The number of active threads forming r, at time *. For ease of exposition, the t is often 
omitted and refers to the current period of Ti so m,(*) = m». Note that there is a time 
lag between thread creation and thread activation. 

A temporary value for m. when threads will but have not yet become (de) activated. 
The worst case budget times summed over all threads forming r,. 

The value ^ for t > j. n,|j is the number of times r, will execute during one period 
defined by Ti. 

The primary budget of process fc, ib g {1,~;P)>.P = number of active processes. Note that 
a process can be active and have its primary thread stopped, in which case some portion 
of its budget is available as timeline slack. This is poor notation actually since the set of 
active processes changes. 

The set of all processes whose unallocated primary budgets are available for slack. 
The sum of the Ofe with budgets available for slack. C = $2*€2 

System level utilization reserved for blocking times. A feasibility test is always of the form 

u <i-u B . 



Table (7) - Periodic Thread Notation 



I Notation | Description 



A 

AA,-,y 

m< 
<<,* 
A.* 

Aperiodic 
TimeKt) 

Idlest) 
&(«) 

«i(<) 
7i(«) - 

U k 


is the amount of timeline slack that was made available from processes with inactive 
primary thread budgets with rate % at time n(t)Ti. Note: A« is not cumulative since the 
beginning of the hyperpeiiod. Also, in the current release of DEOS, it is always true that 
A, = 0 fori €{2,..., n}. 

The vector (Ai, A2, A„) which is maintained at run-time. 

The amount to change rate A; the next lime the start of periods defined by T$ and Ti . 
coincide. It will be the case that for?i-> j, AA;> = 0. Values of AA,) are updated to 
reflect user thread (de) activation requests at level t with an inactive primary thread at 
level j. Note also that if there are no primary threads active at rate s, then AA,_, = OVj. 
The number of threads in aggregate thread r% for % = 1, ... t n. m f - = m%(i). 
The k th thread in r;, for k = 1, ...,m,\ 
The budget of Set when Uk is created. 

The actual execution time of Uk for the current dispatch. If the current dispatch has 
completed then it is the total time that dispatch of i»* took to execute. 0 < < 
A boolean value indicating n*s activation status. If n is active, Ei = TRUE otherwise Ei = 
FALSE. This value is maintained at runtime. 

the amount of level t aperiodic time consumed in [7i(t)7}, t]. For simplicity, we denote 
ApcriodicTimei(t) =. AperiodicTimei. 

the amount of "level" i idle time (i.e. time spent running the idle process) in [7»(*)Tm*] 
no longer available to slack. For simplicity we denote XdUe^fO — XdU&i* 
a conservative estimate of the amount of level i idle time that is lost as level t reclaimed 
slack due to sitting idle. 

The amount of slack reclaimed by completing for period at level t in [7»(t)Ti,t]. 

The period identifier for Ti, For * € {1,2, ...,n}, 7,(i) = [^-J. Alternatively, one can think 

of yi as the dispatch identifier for ri,7i € {0, 1, ...jiT/Ti — 1}. 

A conservative value of the amount of level k slack available that can be carried over to the next 
period T k . 


CuiID(i) 

uoys 

AUSys(l..n) 


This is associated with the system, and uniquely identifies the period T». Comparisons of 
the form P.ReqlD(t) < CurlD(i) will appear in the algorithms. Sometimes these will be 
abbreviated P.*k < 7,, where uniqueness is understood. See comments in the text about 
counter roll over. 

QveiAtn »i# ttvv a tinn a11n/*-a t/\ srtlVP nTATMCPC inflll/IITl tT YlPTlfliniT Tf/ITl TJs TOT fTP- 
OySvem UlLUZillOIl ailUCillCU %K9 oLUVC JllWV-Caoto, lllvJUUillg pcUUUIg ic^ucow 1\J 1 

ation/activation and deletion/deactivation. Note that USys does not necessarily reflect 
the current utilization allocated to active processes. 

Changes to the actual process utilization allocated to active processes that will take place 
at the next period boundary of Ti , at level t. 




The remainder of full Tj periods remaining in the current (relative to t) Ti period. In 
symbols, = L((7i(0 + l)Ti - t)/T;J^ 

The remainder of any unused fixed budgets belonging to ISR threads at rates l,...,j in 
the interval [t, (7i(<) + 1)2)]. 

The sum total of all fixed budgets belonging to ISR threads at rates l,.. ,i in any T> 
period. In this release of DEOS, if B(t) is the worst case "aggregate" ISR fixed thread 
budget (at timei, since ISR threads can be killed/created), flj(i) = nj\iB(t), a quantity 
that should be easy to maintain at runtime. 



Table (8) - 



Slack Scheduling Notation 



ft 



Notation 



Description 



] 



User Budget 



MajcBudget 
Rate 



Active * 

ProcActive 
ReqlD(i) 

7i 

ABudgetReq(t') 



The total amount of time (normalized by the process' primary thread's period) allo- 
cated to active users within the process. UserBudget will never exceed MaxBudget, which 
is the process' entire budget. UserBudget reflects any pending changes indictated by 
ABudgetReq. Consequently, UserBudget is not necessarily the current value of the pro- 
cess' budget assigned to user thread. But that value can be computed. 
The process' total budget, normalized by the period of its primary thread. The term 
budget is somewhat misleading. Utilization is a more descriptive term. 
The rate at which the highest priority thread (including the process' primary thread) runs. 
Note that no user thread of a process p will have a rate higher than the process' primary 
thread. It is TBD whether there is benefit in having a primary thread with rate higher 
than any of its users. Rate takes on one of the values l,...,n, with 1 the highest rate, and 
n the slowest rate. 

A boolean value set to TRUE when the* primary thread is active and false when the primary 
thread is inactive. When p.Active is FALSE, the primary thread's budget is made available 
as timeline slack. 

A boolean value set to TRUE when the process (not just its primary thread) is active, 
otherwise it is FALSE. -» P.ProcActive =^ -> P.Active (regardless of its value). 
This uniquely represents the most recent time a request for user thread (de)activation has 
been made at level t. Note: it is not sufficient to use 7, since these table values are not 
updated "periodically'*, but only when other (de)activations take place after the requests 
have been processed. 

We sometimes denote P.ReqlD(i) by P. 7, where it is understood that P. 7, uniquely defines 
the request period T, . 

This is the amount of change in allocated budget at level 1 that either will or did occur 
at time (ReqlD^t) + l)Ti. If the change hasn't yet occurred, subsequent requests might 
change this value. 



Table (9) - Process Record Attributes (Budget Update Vector) 



Notation 



Description 



ComputeTime 
CT 

ExecTime 
ET 

TimeSlice 



TS 
Ei 



ExecutingOnSlack 



The total compute time allocated to the thread. A timeout will be enforced to ensure that 
a thread does not exceed its worst case compute time. 
An abbreviation for ComputeTime. 

The total time spent executing so far. This time is updated at each thread preemption or 
suspension. 

An abbreviation for ExecTime. 

The amount of time a thread is allowed to execute prior to a hardware timeout. Ex- 
amples of timeouts are maximum mutex execution times and maximum available slack 
consumption before thread suspension. 
An abbreviation for TimeSlice. 

A boolean, denoted by Ei for aggregate thread n which is true if all threads at rate t have 
a true value for CompletedForltsPeriod and false otherwise. 

A boolean value which is true when a thread's budget current budget has been from taken 
from the slack pool and false when it is a part of its fixed budget. 



Table (10) - 



Thread State Time Variables 



Notation 


Description 


Slack 


A record perhaps indexed by slack level (depending on the slack consumption algorithms) 
containing the amount of slack reclaimed at level t and the most rer<*nt nprirwl r P: r! urine* 
which it was reclaimed. 


Slack. 7» 
Slack. 7£; 


The identifier of the most recent Ti period during which level t slack was consumed. 
i € {0, ...,ff/Ti* — 1}. This attribute is not used in the maximal update set of algorithms. 
The amount of slack reclaimed by completing (early) for period at level i within the 
"current" period defined by 7, . Slack.Tl, is set to zero at every period boundary defined 
byTi. 

An abbreviation for Slack. which works only when the slack record is not indexed. 
The amount of unused slack at level 1 that has been carried forward at time 7;(t)T«. 
Slack.!/,* is recalculated at every period boundary defined by T%. 

An abbreviation for Slack. £/»-, which again works only when the slack record is not indexed. 


Hi 

Slacks 
Ui 


Slack(i) 


The slack record associated with a slack consuming thread (if any) at level jr. In this 
situation, slack made available at the higher rates is allocated directly to high rate slack 
consumers, without taking away (or recalculating) slack previously allocated to low rate 
slack consumers. This record is not used in tlie maximal update set of algorithms. 



Table (11) - Slack Record Attributes 



APPENDIX B - ALGORITHMS 



— Algorithm UpdateldleSlackVariables(t: in priority); 

— This algorithm updates the idle slack variables used when computing slack availability. 

— It is called whenever a periodic task completes. 

— update -time = the worst case time to execute this routine, a constant (perhaps based on t). 

Ei := (Ei + l)mod^r; - update the activation status 
idlejtimejconsumed := execution Jime(r«); 

slack-reclaimed := worst jcase-execution_time(r t ) - idlejtimexonsumed; 
for j := 1, t — 1 loop 

Tj Xy + idle-consumed + updated ime; 
end loop; 

for j := l,.. M n loop 

Tj - slack-reclaimed + updateJtime; 

end loop; 



Algorithm (1) - Update Idle Slack Variables 



— Algorithm UpdateAperiodicSlackVariables(t: in priority, t : slack consuming thread); 

— This algorithm updates the aperiodic slack variables used when computing slack availability. 

— It is called whenever an aperiodic task completes, which might include surplus compute time for a periodic 

— task increment, or the idle task completing. 

— update-time = the worst case time to execute this routine, a constant (perhaps dependent on t j. 

the aperiodic task t may execute over several time increments, i.e. it may be scheduled, 

consume all slack, suspend itself, be rescheduled when more slack is available, etc. 

slackxonsumed *.= execution-time JsinceJast-scheduling(t); 

for i :— 1,.. M * - 1 loop 

Jj := Xj + slack-consumed + update Jime; 

end loop; 

for j := t, ...,n loop 

Tj := J, 4- update-time; 

Aj := Aj + slack-consumed; 
end loop; 



Algorithm (2) - Update Aperiodic Slack Variables 



t 

- Function AvailableSlack(t: in priority) return time; 

- This algorithm calculates the slack available beginning at the time of the call and ending at the 

- end of the period defined by assuming no new threads were created and no existing threads are destroyed. 

slack jcalc_time :=: the worst case time to execute this procedure (perhaps based on «). 
for j := 1, ...,t - 1 loop 

Tj := Jj-f slack jcalc-time; 
end loop; 

for j := t, ...,n loop A 
Jj := Jj+ slackxalcjtime; 

end loop; 

slack^available := min l<J<n Sj; 
return slack-available; 

in practice, return zero if slack^available < cswap time +£; y 

updateAperiodicSlackVariables should be called prior to execution of this routine, if necessary. 



Algorithm (3) - Available Slack 



Indefinite Timeout Protocol(c : caller; r : resource); 

if not-Available(r) then 
if c.has -successors 

then estate := CompleteForPeriod; 

reH&m^ 

dequeue(c l queue(r)) ; 
else 

if c.ExecutingOnSlack then c.budgetjremaining available jslack(crate); end if; 
if c.budgetjremaining < queue-time (c) 

then estate := CompietedForPeriod; 

slack reclamation may not be worth it here^ 

else 

enqueue(c,queue(r)); ; ' 

if c, Slack and SlackOn 

then re^ - c.resource^ime(r)); 

estate := Passively WaitingForEvent; 
^redecfemeni slack accumulators by eresour centime (r) ; 
else 

estate := ActivelyWaitingForEvent; 

This type of wait introduces effective blocking. 

end if; 
end if; 
end if; 
else 

if c.ExecutingOnSlack then ebudget .remaining :==^vailableislack(c.rate); end if; 
if ebudget ^remaining < resource-time(r) 
then estate :=s CompietedForPeriod; 

release(r); dequeue(c,queue(r)); 
else continue the execution of c with resource r available; 

Slack a^cximul a tors need to be predecremented if c is executing on slack and r is a mutex. 

end if; 
end if; 



Algorithm (4) - Indefinite Timeout Protocol for a Resource Wait 



Long Duration Timeout Protocol(c ; caller; r : resource; numJter : natural); 

if not-available (r) then 
if numJter = maxJter 

then dequeue (c,queue(r); return; 
else numJter := numJter -f 1; 
end if; 

if c.has-successors 

then estate := CompIcteForPeriod; 

g;£jee^ 

aequeue(cir); - At the next start of c's next period, c will be moved to r's queue by DEOS 
else 

if c;ExecutingOn Slack then c.budget .remaining := available .slack (crate); end if; 
if c.budget -remaining < queue -time (c) 

then estate := Completed ForPeriod; 

islaWfredamatiw not be worth it here 

else 

enqueue(c,queue(r) ) ; 
v^eSlack and SlackOn 

thenredara - c.resource-time(r)); 

estate := PassivelyWaitingForEvent; 
predecrement slack accumulators By c. resource-time (r); 
else 

estate ;= ActivelyWaitingForEvent; 

— — This type of wait introduces effective blocking. 

end if; 
end if; 
end if; 
else 

if eExecutingOnSlack then c.budget jemaining := available-slack (crate); end if; 
if c.budget -remaining < resource_time(r) 
then estate := Completed ForPeriod; 

release(r); dequeue(c,queue(r)); 
else continue the execution of c with resource r available; 

— vc Slack^ccum c is executing on slack and r is a mutex. 

end if; 
end if ; 



Algorithm (5) - Long Duration Timeout Protocol for a Resource Wait 



Short Duration Timeout Protocol(c : caller; r : resource); 

while apriority <:r ready Jthread,(inherited)priority 

wait; — — higher or equal priority threads are running 
end while; 

c is at the head of queue(r) 

if not-available (r ) 
then 

return timeout status to c; dequeue(c,queue(r)); 
estate := CompIetedForPeriod; 
else 

case r .type is 

when r ss event => continue the execution of c with event r pulsed; 
when r = mutex => grant c the lock to mutex r; 

— when c is executing on slack, gi^e^einent the slack accumulators 
when r = semaphore => c calls wait(r); 
end case; 
end if; 




Algorithm (6) - Short Duration Timeout Protocol for a Resource Wait 

- Algorithm SystemlnitializationOfSiackVariabies; 

- This algorithm is called once before the start of the initial hyperperiod. 

- Failure to initialize slack variables at this time wiU result in bogus values later. 

- This algorithm requires modifications when primary thread periods can be other than Ij . 

£:=«; 

C:=0; f 0 :=0; 

for each process P in the registry loop 
calculate/read P's budget, Cp; 

P.UserBudget := 0; RMaxBudget := ( p ) P.Rate := 1; 

P.ReqID := (0,0, ...,0); P.ABudgetReq := (0,0, ...,0); vectors of n zeroes. 

— Most likey, if P.ProcActive, then P. Active will be assumed at system startup? 
if P.ProcActive then 

if P. Active then — P's primary .thread is active 

then Co := Co + C P ; 
elseC:=C + Cp;-Z:=^U{P}; 
end if; 
end if; 
end loop; 

for t := l t ...,n loop 

Ti := the period of the i th smallest rate declared in the system; 
Ai :=r 0;C* := execution time of t, j 
AUsys(i) := 0; 
for j := 1, loop 

n lti := Ti/Ty, AAij := 0; ' , \ 

— (njjj), (/\Aij) are diagonal matrices, 
end loop; 
end loop; 

Ai -Ti-K + Co + fjs); 

Ai := system level slack = budget not assigned to active processes minus system blocking time 

USys:=(C + Co)/r i: 



Algorithm (7) - System Initialization of Slack Variables 





Algorithm PeriodUpdateOfSlackVariables(j : in rate); 

This algorithm is called at the start of every period. That is at times O f Tj , 2Tj t ... 

This algorithm is called once at the largest period. That is, the start of a period for Tj 
is also the start of a period for T k when k < j. 

r indexes the rates at which primary periods are supported. 1 

In the current release of DEOS, r = 1, always, so this is an O(n) routine. ' 

When thread (de)activations occured, update changes in dynamic period timeline slack. 

Ohe may have to introduce process sets with indices for their primary threads. 

ZtzzZ 1 ; Z':=Z; 
for k := l.J loop 

U k is a conservative amount of level Jb slack available and not used in the last T k period that can 
Not all of Uk can be attributed to Uk but can safely be assigned to U n - 
U k := Uk + max(O t (A* - (A k + T fc )); 
U n i=U n +H k ; 

l k := 0; A k := 0; K k := 0; L k := 0; 
E k := FALSE; -Yfc — tk + 1; 
AUsys(ik) := 0; 
<r := 0; 

— In this release of DEOS, the loop here is simply A k A k + X^=i AAi r ; 

— and then zero out the Av4i r entries, 
for r := k..j loop 

<r := <r + AAjb r ; 



AA fcr := 0; 
end loop; 
Ajk := A fc + <r; 
end loop; 



if j s n then 

for k := l..n loop 



we are at the hyperperiod, reset the period id's and unconsumed slack. 



7fc := 0; 
U k := 0; 
end loop; 



end if; 



Algorithm (8) - Period Update of Slack Variables 
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— Algorithm PrimaryThread(De)activation(P : process); 

If P.active, then deactivate P's primary thread else activate P's primary thread. 

(De)activation request "processing" time is at s t where y r T r < s < (y r + l)T r , with r s P.rate. 

Notation used denned below and is the same as that above. 

n jlr = Tj/T r . 
r := P.rate; 

£3 There may be some pending requests for activations/deactivations that will not be in effect at time hrh) + l)T r . 

* ^ for j := r..n loop 

J"} if RABudgetReq(j) > 0 and then CurlD(j) > P.ReqID(j) then 

. I: These updates have already occurred. Zero them out. 

I I RABudgetReq(j) := 0; P.ReqID(j) := 0; 

¥ * end if; 

rg if (CurID(j) = RReqID(j) and ((7; + 1)7; > (*y r + l)r P )) then 

y P.UserBudget ;= RUserBudget - &BudgetReq( j)/n jlr ; 

a Z ABudgetReqk) is left unchanged for later updates. 

end if; 

* if RActive then 

AA rr := AA rr - (P.MaxBudget - P.UserBudget )T r ; 
fSj else; 

f[j AArr := AA rr + (RMaxBudget - RUserBudget) T r \ 

, P \ end if; 

end loop; 

^ if RActive then P.Active := FALSE else RActive := TRUE; end if; 



Algorithm (9) - Updates for Primary Thread (Deactivation Requests 
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— Algorithm UserThread( Deactivation (5: time; j rate; P: process; activation : boolean); 

— P is the process of the thread being (de)activated. 

— j is the rate of the thread for which (de) activation is being requested. 

— 6 is +/— the budget of the thread (in time, not utilization) requesting de/activation. 

— I.e. 6 < 0 the call is for a deactivation request, and S > 0 the call is for an activation request. 

— activation is a boolean, which is actually redundant information given £'s sign. 

— Can we admit a new thread at level j? 

— (De)activation request time is at 5, where 7 7 Tj < s < (*yj + l)2j. 

— This assumes that deactivations have at most a one period delay, which is coming soon. 

— The execution of this code is at time s, with period boundary code executed at time + l)Tj. 

Notation used defined below. 

n il* ~ T i/ T h- 

r := Pa-ate; P's primary thread's rate. 

CurlD(i) is similar to *y J ( except it must uniquely identify which period Tj we are in since 

P.CurlD might not have been updated for many hyperperiods, hours, or since system boot. 

for t := 1, ..,n loop 

if P. ABudgetReq(j) / 0 then 

if CurlD(t) > P.ReqlD(t) or P.ReqlD(i) - CurlD(i) > n nll then 
P.ReqlD(t) := 0; P.ABudgetReq(t) := 0; 

These updates have already been made. Zero them out. 

end if; 
end if; 
end loop; 

If an activation check for feasibility, and if feasible readjust' the Compute times within the process. 

if activate then 

UserBudget :=P.UserBudget; 

for t := j + l..n loop 

UserBudget := UserBudget - min{0,P.ABudgetReq(i)); 

end loop; 

if UserBudget +S/Tj > PMaxBudget 
then 

reject the activation request on the grounds of infeasibility; 
return; 
end if; 
end if; 

P.UserBudget := P.UserBudget -f 5/Tj; 

P.ReqID(0 := PCurlD(i); P. ABudgetReq := P. ABudgetReq + $/Tj ;; 
if not P.Active then 

AA r|J := AA riJ +S/n i | r ; 

Here is where we would update AC r j if aggregate threads are used. 

-end if; 



Algorithm (10) - Updates for User Thread (De) Activation Requests 



it 



- Algorithm Process (De)activation(P : process, r : rate; activate : boolean); 

- This request is made at time t. If granted, it will become effective at time (-yr(t) + l)T r where r := P.Rate; 

( p the worst case compute time of P measured every T r time units. (This would be input in a create.) 
if activate 
then 

if P.Proc Active then return either an with error or as a no-op; end if; P is already active. 

Determine whether activating P will result in a feasible' process, set. 

SysBud := SysU; 

for t := r + 1, ... t n loop 

SysBud := SysBud - min(0, ASys(i)); 
end loop; 

if SysBud +< P /T r >1-U B then 

reject activation request; return; infeasible 

end if; 

Activation is feasible 

RRate := r; P.Active := TRUE; P.ProcActive := TRUE; 
P.MaxBudget := ( p ; P.UserBudget := 0; 
PrimaryTh read Act ivation(P); 
ASys(r) := ASys(r) + < P /T r ; 
else a deactivation request which have no feasibility test 

if P.UserBudget ^ 0 then return error; end if; 
P rimary Thread Deactivation^ P ) ; 
P.ProcActive := FALSE; 
ASys(r) := ASys(r) - ( P /T r ; 
end if-then-else; 

This is another place where the AC matrix is updated, and also Z' . 

TK& I^CHCT Way II^T bft.tfc6sltti when all processes are assumed to be declared statically. 



Algorithm (1 1) - Process (Deactivation 



Algorithm U pdateReclaimed Slack (i: in priority); 

This algorithm updates the reclaimed slack variables used when computing slack availability. 
It is called whenever a task executing on fixed budget completes for period: 
The same algorithm applies whether doing incremental or aggregate updates. 



if r, has completed then 

slack-reclaimed := ComputeTime(f ( )- ExecTime(ri) - updateJtime; 

updateJime is the time to execute this code 

71; := 7£»*-f max (0, slack-reclaimed - £,); 
end if; 



Algorithm (12) - Update Reclaimed Slack Variables 



1 ft 

— Algorithm UpdateidleSlackVariables; 

This algorithm updates the idle slack variables used when transitioning from busy to idle. 

— It is called whenever when the idle task completes (at priority (n-H)). 
I.e. the idle process is denoted by r n +i . 

update-time =r the worst case time to execute this routine. 

idlejtime := ExecTime(r n +i); 

The assumption for DEOS is that idleJtime < T%* 

To relax that assumption would require more bookkeeping. 

j := 1; 

while idle -time > 0 and j < n loop _ ~ , v 

-- slfcfc-aMflUlat (e. ( Ai ^ + fcj) ~ (A i 4- Ti) 

if idle -time < slack available then ^ <J \I 

Tj := Tj+ idleJtime; idle-time := 0; 
end if; 

Cj is defined as the worst case compute time, but can be reduced 

to the worst case amount of time threads at level j can wait for a resource 

and not give up their time to the slack. 

In DEOS, as I understand it, this is only ISR threads which run at rate 1. 

I believe the algorithm works for threads that can wait for resources while holding budgets. 

I also think under these conditions, it is suboptimal. 

if slack-available < idle -time and idle_time < (A^ + Uj -|- Cj) then 

Tj := Xj+ slack javailable; 

jCy := Cj\ (idleJtime - slack-available); 

idle_time := 0; 
end if; 

if idle-time > (A, -f Uj -f Cj) then 
Tj := Tj + slackjavailable; 
Cj := Cj -f (Aj + Uj + Cj)- slack-available; 
idlejtime ;= idlejtime - (Aj + Uj -f Cj); 
end if; 
end loop; 



Algorithm (13) - Update Idle Slack Variables 

Algorithm UpdateAperiodicSIack Variables (t: in priority, t : slack consuming thread); 

This algorithm updates the aperiodic slack variables used when computing slack availability. 

It is called whenever an aperiodic task completes, which might include surplus compute time for a periodic 

task increment, or the idle task completing. 

up date-time = the worst case time to execute this routine, a constant (perhaps dependent on t). 

the aperiodic task t may execute over several time increments, i.e. it may be scheduled, 

consume all slack, suspend itself, be rescheduled when more slack is available, etc. 

slack-consumed := execution^ime-sinceJast-scheduling(t) -f update-time; 
i :== 1; 

while slack jconsumed > 0 loop 

1)8 ;= min(slackxonsumed, max ((A, -|- IZj + Uj) — (Tj -f- Aj+ slackjconsumed),0)); 

slack jconsumed := slack jconsumed — ljs; 

Aj Aj+ Us; 

i := i + 1; 
end while; 



Algorithm (14) - Update Aperiodic Slack Variables 



Function AvailableSlack return an n-vector of slack time = (5(1), 5(2), S(n)); 

This algorithm calculates the slack available beginning at the time of the call, say s and ending at the 
ends of periods denned by (( 7l (s) + 1)T 1( {<y 2 (s) + l)T 2l ....(-*»(*) + l)T„). 

Note that more period timeline slack may become available in these intervals after this request. 

This differs significantly from the original slack stealer. 

Note the difference in fonts for Ai and Ai. They are different variables. 



slackxalctime the worst case time to execute this procedure; 
Sf/:=0; 

for j := l..n loop 

S := (Aj + 7lj + Uj) - (Aj + Jy+ slackjcalcjtime); 
Su := Su + S; 

if Su < 2 (cs wap + 8) -f cachebonus 

then 5,* := 0; 

else Sj := Sr/ ; 
end if; 
end loop; 

returnS = (5i ,5 2 , ...,5„); 

in practice, if the slack available at any level is too small to cover the cost of context swaps , 

plus other overhead, using it causes a negative effect. 

5 and cacheBonus is selected based on system overheads beyond cswaps. 

Update Ape nodicSlack Variables should be called prior to execution of this routine, when necessary. 

UpdateldleSlack Variables will have automatically be called 1 prior to exection of this routine. — 



Algorithm (15) - Available Slack 



